Integrated development environments (IDEs) provide a common platform and design tools for modern software development. While software is often the most time-consuming and highest risk aspect of electronic product development, it also holds the greatest potential to enhance a design for multiple target applications. Such design tools allow designers to efficiently develop code where graphical user interfaces (GUI) automates and simplifies the configuration of complex programming projects. These tools also enable designers to create source code by enhancing code readability and simplifying code writing. For instance, source code editor features may include syntax coloring, auto-indenting, and shortcut menus that link stored procedure calls to their definitions, declarations, and usages even when these references reside in separate files. Other aspects of the tools include simulation resources to allow designers to develop and debug applications when hardware resources are scarce or unavailable.
One area of software development that is performed on IDEs includes mapping class objects to relational objects, referred to as O/R mapping, and is the latest advancement in modern day programming technologies. It improves the productivity of programmers by many degrees while providing flexibility to adapt to changing business needs. While O/R technology itself provides many benefits to programmers, enabling O/R classes to be created and set up correctly is not an easy task for normal development nor is it well-supported in current programming tools. Without providing adequate tools support, programmers trying to adopt the technology may be forced to write their respective code manually.
One purpose driving O/R technologies is the need to interface the relational database world with the models supported in the object oriented programming world. For example, relational database management systems (RDBMS) supporting the relational database predated the popularization of object-oriented programming in the 1990s. Using relational databases to store object-oriented data leads to a semantic gap where programmers would be required to allow their software to function in two different worlds—processing of data would be performed in object-oriented form, but the same data would have to be stored in relational form.
Requiring this constant conversion between two different forms of the same data not only had the effect of stifling performance, but imposed difficulties to the programmer as the relational or object-oriented forms would impose limitations on each other. For example, relational databases make complicated associations difficult, and they tend to “map” poorly into the object oriented world since they fail to implement the relational model's user-defined types. This problem is sometimes referred to as the Object-Relational impedance mismatch.
When developing multi-tiered, data-centric software in the O/R domain, it is often desired to have clear separations between different logical layers such as presentation layer, business logic layer and data access layer. This becomes more evident as complexity of software architecture increases. Also, introduction and fast adoption of new technologies such as web services often demand that the architecture of software be flexible and modular so that developers can take advantage of new techniques without making significant changes to the application design.
Although many present design systems provide design time data tools that help developers rapidly build data-centric applications with minimal coding, these lack the native support for developers building multi-tiered data-centric applications. For instance, there are often limitations with workspace components (e.g., Dataset Designer) to have business logic (e.g., Data Table) mixed together with data access logic (e.g., Table Adapter), where developers do not have an easy way to migrate their single-tiered architecture to multi-tiered architectures as their business requirements evolve. Rather, developers are often forced to go through generated code, carefully separate out business logic and data access layers into separate assemblies and add proper references manually.
In another regard, when using present design tools to generate code based on a model created and modified within the tools, it is sometimes necessary to manually split different sections of generated code to different target projects. Since a single interface is often employed to manipulate the model, it is also desirable to properly update split code when changes are detected from the tools without having to also perform such updates manually.